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5 A METHOD AND SYSTEM FOR PROTOCOL SELECTION 

FIELD OF THE INVENTION 
% The invention relates to network communication, specifically to selecting a protocol 

y> for the network communication. 

y = 

W BACKGROUND OF THE INVENTION 

h\ In a computer network system employing object technology, services are handled by 

=p objects. Objects are independent program modules that may include data as well as functionality. 

H Objects may communicate using a common interface called an object request broker ("ORB") 

designed according to Common Object Request Broker Architecture ("CORBA"). CORBA is an 
industry standard architecture for distributed objects. In CORBA, the client makes a request to the 
ORB which directs the request to the appropriate server and redirects the results back to the client. 
Each object is identified by an object handle called an interoperable object reference ("IOR"). 

20 Typically, an object is located at the server and the client only has the IOR. The same object may 
be located on several computers but may nevertheless have only one IOR. Upon issuance of a 
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request for an object by way of IOR, the ORB will determine which instance of the object to 
reference. If an object is co-located at the client, the ORB would typically attempt to use the co- 
located object preserving efficiency of resources. However, if there is no co-located object or for 
some reason it is not usable, the ORB uses the information contained in the IOR to communicate to 
an appropriate server where an instance of the object is located. 

Once the ORB determines the remote location for the targeted object, (the object is 
not located on the computer requesting the object), communication must be established between the 
two computers. Network communication is established using protocols, which are the rules 
governing transmitting and receiving of data. Typical protocols include TCP/IP (Transmission 
Control Protocol/Internet Protocol), ATM (Asynchronous Transfer Mode), HTTP (Hyper Text 
Transport Protocol), and HOP (Internet Inter-ORB Protocol). For secure communications, SSL 
(Secure Sockets Layer) may be employed in conjunction with another protocol. 

A remote object reference in a distributed environment may contain a multitude of 
protocols and/or connectivity options. A client that is attempting communication must select one 
of these options to establish the connection with the remote object. There may be many constraints 
and variables associated with such a selection: client middleware infrastructure's support for certain 
protocols; client or user privileges to use certain communication channels; user preferences for 
communication channel characteristics; and relative efficiency of protocols. The IOR may identify 
the one or more protocols that the object it represents recognizes and is able to use. Where more 
than one protocol is specified, a selection process is needed to determine which protocol to employ. 
Conventionally, the ORB made this determination by trying different protocols in random order or 
in a predefined static order. For example, the order may be defined as the order in which the 



protocol modules were registered or initialised with the system. Another approach is to specify an 
order of preference among the potential protocols so that the order is fixed at the time of 
compilation. 

What is needed is a more strategic method for selecting protocols. In addition what 
is needed is a flexible method where the basis for the selection may be set by the user. This 
invention satisfies these and other needs. 

SUMMARY OF THE INVENTION 
The bidding method for selecting a protocol involves generating a bid for each 
protocol, ranking the bids in a prescribed order, and then using the best protocol according to the 
ranking. If for some reason the best protocol is unsuccessful, use the next best protocol, processing 
the protocols in the order of the bid ranking. A typical ranking is the lowest value bid takes the 
highest ranking. 

Using a bidding process for selecting a protocol, allows for introduction of varying 
degrees of flexibility in determining the protocol. The bidding process may account for variables 
and constraints such as client middleware infrastructure's support for certain protocols; client or user 
privileges to use certain communication channels; user preferences for communication channel 
characteristics; and relative efficiency of protocols. The effect of implementing the bidding process 
of the present invention is a dynamic protocol selection process. In addition, protocol modules may 
be added or removed without requiring any redesign or adjustment of the selection process. 

To provide the user with control over the selection process, the configuration 
associated with the client or with the application is designed to include one or more properties that 


may be set by the user. Properties may indicate, for example, to always use a secure method of 
communication or always use a proxy. If a property is set indicating exclusive use of certain 
protocol, then for protocols not satisfying the properties will not be selected. 

Further dynamic protocol selection is achieved by conceptually dividing the ranking 
into ranges where each range is defined by a rule to achieve a certain priority/preference ranking. 
Bid values are determined based on the profiles in the IOR and configuration set by the user. The 
bids inherently fall into one of the prescribed ranges indicating the priority level associated with the 
protocol represented by the bid. There may be, for example, a range indicating exclusivity. If there 
are any bid falling within the exclusivity range, the associated protocols will be tried but protocols 
associated with bids in any lower priority range will not be tried. There may be, for another 
example, a range indicating critical protocols. Protocols associated with bids in the critical range 
will be tried first. The configuration contains several settings for the user to define the desired 
priority among the protocols. The settings may take the form of list of protocols falling within a 
desired priority. For example, the configuration may include a critical protocols list where the user 
specifies those protocols that must be tried first. Another list may indicate the protocols that are to 
be tried exclusively. The user may also define a priority for ordering protocols falling within a 
single range. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 shows an environment for the preferred embodiment of the present 

invention; 

Figure 2 shows an embodiment of the present invention; and 
Figure 3 shows a preferred embodiment of the present invention. 


DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
Referring to Figures 1 and 2, during the course of processing of an application at a 
client 10, the need arises to evoke a specific object 20 remotely located at the server 12. The IOR 
(intercep table object reference) 16 associated with the targeted object is pushed to the ORB (object 
request broker) 18. The IOR contains information 32 about the type of object being referenced and 
one or more profiles 34. Each profile represent a protocol, i.e., a way to contact another computer, 
typically a server. HOP and TCP are a typical protocols. For secure communication IIOP/SSL is 
a typical protocol. A profile may contain one or more components. Components are typically 
communication processes that perform on top of or in conjunction with a protocol. For example, 
where communication must pass a proxy such as a firewall, the proxy server is indicated as a 
component of the profile, and the specified protocol, e.g. HOP, will operate under or using the 
gatekeeper. Another example is where the communication must be secure, SSL may be indicated 
as a component to be used with a protocol e.g. TCP. The term protocol is used broadly so as to 
include components such as a proxy server and SSL as well as independent protocols such as TCP 
and HOP. At the client there is are protocol modules 22 each containing the instructions (i.e. code) 
for operating a particular protocol to establish communication between the two computers (e.g., 
client and server). Furthermore, each protocol module has an associated bidder 24, containing logic 
for generating a bid according to the IOR 16, the setting of the configuration 26, user preferences 
38 and target object constraints 36. Target object constraints are name value pairs, for example, 
"always secure, true" is an example of a typical target constraint. 

When the ORB at the client receives the IOR specifying multiple protocols, it must 
determine which protocol to use. The one or more protocols are individually identified in the IOR 
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in its profiles. Each protocol bidder check the profiles in the IOR to determine whether is 
recognizes any of them. If it recognizes one of the profiles it submits a bid. If it does not recognize 
any of the profiles, it does not submit a bid. Alternatively, the ORB solicits bids from each protocol 
bidder is registered with the ORB. 

Each protocol bidder determines the value of the bid to submit either from the 
information previously defined by the user in its configuration 26 or by using the default value. The 
default values are assigned to the protocol modules or bidders at the time the protocol module is 
established. 

If the user wants to specify that certain protocol be used under certain circumstances, 
the user sets the configuration 26 at the client. The configuration includes properties that relate to 
the use of the protocols. The user specifies how the protocols should be used by setting these 
properties in the configuration. For example, if the user want to specify that all communications 
must be transmitted over a secure protocol, the user sets the always_secure property. Another 
property is called alway_proxy which indicates that all communications must pass through the 
gateway. 

The bid value is determined based on the properties settings in a predefined manner. 
If always_secure is set then SSL protocol submits a very low value, so that it gets priority over the 
other protocols. In addition, if alway_secure is set then the protocols which do not provide secure 
communication will not submit a bid because otherwise, if the SSL protocol fails then an insecure 
protocol will be tried, contrary to the property setting. If no properties are set or if a protocol is not 
affected by the specified properties, then the default values are submitted. Instances where a 


protocol does not submit a bid include where the property settings preclude the protocol or where 
the protocol does not recognize the definitions in the profiles. 

The submitted bids are entered into a table called a portfolio. The bids are typically 
ordered in ascending order. To establish a connection to the server, the protocol associated with the 
lowest bid (highest preference or priority) is processed. If communication fails, the ORB processes 
the protocol associated with the next bid in the portfolio. 

In a preferred embodiment, the portfolio is subdivided into a plurality of ranges. Each 
range is associated with a predefined rule reflecting its priority relative to the other ranges. For 
example there may be three ranges, named critical, exclusive, and normal. The critical range is 
defined by the rule that the protocols submitting bids within this range have the highest priority and 
are to be tried first. An in-process (i.e., a co-located object) transport is typically assigned a bid 
within the critical range. The exclusive range is defined by the rule that the protocols submitting 
bids within lower ranking ranges are not processed even if all the exclusive protocols are 
unsuccessful. For example, SSL is typically assigned a bid within exclusive range. The normal 
range is defined so that only if there are no bids submitted to the exclusive range will the protocols 
in the normal range be processed. 

To implement this range system, the configuration has settings in addition to or 
instead of properties. The configuration provides for an order list of protocols where the user may 
define the order of priority among protocols that bid within a single range. In addition, the 
configuration provides for user defined lists for each range other than normal. Continuing with the 
example of three ranges described above, the configuration includes an exclusivity list and a critical 
list. 


When determining a bid value for a protocol, the protocol bidder references the 
configuration 26, target object constraints 36, and user preferences 38. If the protocol is listed on 
the exclusivity list, then the bid value with be set within the exclusivity range 44 and entered into 
the portfolio 40. If a protocol is listed on the critical list, the associated bid value will be within the 
critical range 42. For protocols not listed, the bid value will be set within the normal range 46. 
Finally, the priority list is referenced and the bid values within a range are adjusted so that the order 
defined by the priority list is preserved. It should be understood by one skilled in the art that 
determining the bid value may be performed in one step or a series of steps without any impact on 
the invention. 

Since the selection of protocols is determined by the configuration which may be 
defined by the user, the selection process is dynamic in contrast to a process fixed at the time the 
application at the client is compiled. 

While the invention has been particularly shown and described with reference to a 
preferred embodiment thereof, it will be understood by those skilled in the art that various changes 
in form and details may be made therein without departing from the spirit and scope of the invention. 
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